FHIR © HL7.org  |  Server Home  |  FHIR Server FHIR Server 3.4.11  |  FHIR Version n/a  User: [n/a]

Resource Requirements/FHIR Server from package hl7.ehrs.ehrsfmr21#current (32 ms)

Package hl7.ehrs.ehrsfmr21
Type Requirements
Id Id
FHIR Version R5
Source http://hl7.org/ehrs/https://build.fhir.org/ig/mvdzel/ehrsfm-fhir-r5/Requirements-EHRSFMR2.1-RI.1.3.3.html
Url http://hl7.org/ehrs/Requirements/EHRSFMR2.1-RI.1.3.3
Version 2.1.0
Status active
Date 2024-11-26T16:30:50+00:00
Name RI_1_3_3_Manage_Record_Entry_Succession_and_Version_Control
Title RI.1.3.3 Manage Record Entry Succession and Version Control (Function)
Experimental False
Realm uv
Authority hl7
Description Manage successive Record Entry versions over time.
Purpose The system must have a mechanism to handle versions and succession of Record Entries (such as a preliminary and final laboratory reports, amended or corrected documents). Versioning and succession management is based on Record Entry content, and/or status change over time. A version may be one of:1) A completed and attested Record Entry; 2) A Record Entry completed and attested which has been modified one or more times3) A Record Entry that has been viewed for clinical decision-making purposes by an individual other than the author4) A Record Entry that has been captured in an incomplete state per organization business rules and updated over time (i.e., a preliminary laboratory test). 5) A Record Entry that electively, according to the author, must be preserved in the current state at a given point in time (i.e., History and Physical). Certain types of Record Entries are typically handled in versions, for example: laboratory results (preliminary and final)- Dictated reports- Work ups (over course of days)The prior version of Record Entries should be retained for the legally prescribed timeframe as defined by scope of practice, organizational policy, and jurisdictional law.

Resources that use this resource

No resources found


Resources that this resource uses

No resources found



Narrative

Note: links and images are rebased to the (stated) source

Statement N:

Manage successive Record Entry versions over time.

Description I:

The system must have a mechanism to handle versions and succession of Record Entries (such as a preliminary and final laboratory reports, amended or corrected documents). Versioning and succession management is based on Record Entry content, and/or status change over time.

A version may be one of:1) A completed and attested Record Entry; 2) A Record Entry completed and attested which has been modified one or more times3) A Record Entry that has been viewed for clinical decision-making purposes by an individual other than the author4) A Record Entry that has been captured in an incomplete state per organization business rules and updated over time (i.e., a preliminary laboratory test). 5) A Record Entry that electively, according to the author, must be preserved in the current state at a given point in time (i.e., History and Physical). Certain types of Record Entries are typically handled in versions, for example: laboratory results (preliminary and final)- Dictated reports- Work ups (over course of days)The prior version of Record Entries should be retained for the legally prescribed timeframe as defined by scope of practice, organizational policy, and jurisdictional law.

Criteria N:
RI.1.3.3#01 SHOULD

The system SHOULD provide the ability to manage Record Entries that become new versions when their state changes (e.g., augmented, amended, corrected, etc.).

RI.1.3.3#02 SHALL

The system SHALL provide the ability to update a Record Entry and save it as a new version.

RI.1.3.3#03 SHALL

The system SHALL capture, maintain and render the date, time and user for the original and each updated version of the Record Entry.

RI.1.3.3#04 SHALL

The system SHALL manage the succession of Record Entries in chronological version order.


Source

{
  "resourceType" : "Requirements",
  "id" : "EHRSFMR2.1-RI.1.3.3",
  "meta" : {
    "profile" : [
      "http://hl7.org/ehrs/StructureDefinition/FMFunction"
    ]
  },
  "text" : {
    "status" : "extensions",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\">\n <span id=\"description\"><b>Statement <a href=\"https://hl7.org/fhir/versions.html#std-process\" title=\"Normative Content\" class=\"normative-flag\">N</a>:</b> <div><p>Manage successive Record Entry versions over time.</p>\n</div></span>\n\n \n <span id=\"purpose\"><b>Description <a href=\"https://hl7.org/fhir/versions.html#std-process\" title=\"Informative Content\" class=\"informative-flag\">I</a>:</b> <div><p>The system must have a mechanism to handle versions and succession of Record Entries (such as a preliminary and final laboratory reports, amended or corrected documents). Versioning and succession management is based on Record Entry content, and/or status change over time.</p>\n<p>A version may be one of:1) A completed and attested Record Entry; 2) A Record Entry completed and attested which has been modified one or more times3) A Record Entry that has been viewed for clinical decision-making purposes by an individual other than the author4) A Record Entry that has been captured in an incomplete state per organization business rules and updated over time (i.e., a preliminary laboratory test). 5) A Record Entry that electively, according to the author, must be preserved in the current state at a given point in time (i.e., History and Physical). Certain types of Record Entries are typically handled in versions, for example:\nlaboratory results (preliminary and final)- Dictated reports- Work ups (over course of days)The prior version of Record Entries should be retained for the legally prescribed timeframe as defined by scope of practice, organizational policy, and jurisdictional law.</p>\n</div></span>\n \n\n \n\n \n <span id=\"requirements\"><b>Criteria <a href=\"https://hl7.org/fhir/versions.html#std-process\" title=\"Normative Content\" class=\"normative-flag\">N</a>:</b></span>\n \n <table id=\"statements\" class=\"grid dict\">\n \n <tr>\n <td style=\"padding-left: 4px;\">\n \n <span>RI.1.3.3#01</span>\n \n </td>\n <td style=\"padding-left: 4px;\">\n \n \n \n <span>SHOULD</span>\n \n </td>\n <td style=\"padding-left: 4px;\" class=\"requirement\">\n \n <span><div><p>The system SHOULD provide the ability to manage Record Entries that become new versions when their state changes (e.g., augmented, amended, corrected, etc.).</p>\n</div></span>\n \n \n </td>\n </tr>\n \n <tr>\n <td style=\"padding-left: 4px;\">\n \n <span>RI.1.3.3#02</span>\n \n </td>\n <td style=\"padding-left: 4px;\">\n \n \n \n <span>SHALL</span>\n \n </td>\n <td style=\"padding-left: 4px;\" class=\"requirement\">\n \n <span><div><p>The system SHALL provide the ability to update a Record Entry and save it as a new version.</p>\n</div></span>\n \n \n </td>\n </tr>\n \n <tr>\n <td style=\"padding-left: 4px;\">\n \n <span>RI.1.3.3#03</span>\n \n </td>\n <td style=\"padding-left: 4px;\">\n \n \n \n <span>SHALL</span>\n \n </td>\n <td style=\"padding-left: 4px;\" class=\"requirement\">\n \n <span><div><p>The system SHALL capture, maintain and render the date, time and user for the original and each updated version of the Record Entry.</p>\n</div></span>\n \n \n </td>\n </tr>\n \n <tr>\n <td style=\"padding-left: 4px;\">\n \n <span>RI.1.3.3#04</span>\n \n </td>\n <td style=\"padding-left: 4px;\">\n \n \n \n <span>SHALL</span>\n \n </td>\n <td style=\"padding-left: 4px;\" class=\"requirement\">\n \n <span><div><p>The system SHALL manage the succession of Record Entries in chronological version order.</p>\n</div></span>\n \n \n </td>\n </tr>\n \n </table>\n</div>"
  },
  "url" : "http://hl7.org/ehrs/Requirements/EHRSFMR2.1-RI.1.3.3",
  "version" : "2.1.0",
  "name" : "RI_1_3_3_Manage_Record_Entry_Succession_and_Version_Control",
  "title" : "RI.1.3.3 Manage Record Entry Succession and Version Control (Function)",
  "status" : "active",
  "date" : "2024-11-26T16:30:50+00:00",
  "publisher" : "EHR WG",
  "contact" : [
    {
      "telecom" : [
        {
          "system" : "url",
          "value" : "http://www.hl7.org/Special/committees/ehr"
        }
      ]
    }
  ],
  "description" : "Manage successive Record Entry versions over time.",
  "jurisdiction" : [
    {
      "coding" : [
        {
          "system" : "http://unstats.un.org/unsd/methods/m49/m49.htm",
          "code" : "001",
          "display" : "World"
        }
      ]
    }
  ],
  "purpose" : "The system must have a mechanism to handle versions and succession of Record Entries (such as a preliminary and final laboratory reports, amended or corrected documents). Versioning and succession management is based on Record Entry content, and/or status change over time.\n\nA version may be one of:1) A completed and attested Record Entry; 2) A Record Entry completed and attested which has been modified one or more times3) A Record Entry that has been viewed for clinical decision-making purposes by an individual other than the author4) A Record Entry that has been captured in an incomplete state per organization business rules and updated over time (i.e., a preliminary laboratory test). 5) A Record Entry that electively, according to the author, must be preserved in the current state at a given point in time (i.e., History and Physical). Certain types of Record Entries are typically handled in versions, for example:\n laboratory results (preliminary and final)- Dictated reports- Work ups (over course of days)The prior version of Record Entries should be retained for the legally prescribed timeframe as defined by scope of practice, organizational policy, and jurisdictional law.",
  "statement" : [
    {
      "extension" : [
        {
          "url" : "http://hl7.org/ehrs/StructureDefinition/requirements-dependent",
          "valueBoolean" : false
        }
      ],
      "key" : "EHRSFMR2.1-RI.1.3.3-01",
      "label" : "RI.1.3.3#01",
      "conformance" : [
        "SHOULD"
      ],
      "conditionality" : false,
      "requirement" : "The system SHOULD provide the ability to manage Record Entries that become new versions when their state changes (e.g., augmented, amended, corrected, etc.)."
    },
    {
      "extension" : [
        {
          "url" : "http://hl7.org/ehrs/StructureDefinition/requirements-dependent",
          "valueBoolean" : false
        }
      ],
      "key" : "EHRSFMR2.1-RI.1.3.3-02",
      "label" : "RI.1.3.3#02",
      "conformance" : [
        "SHALL"
      ],
      "conditionality" : false,
      "requirement" : "The system SHALL provide the ability to update a Record Entry and save it as a new version."
    },
    {
      "extension" : [
        {
          "url" : "http://hl7.org/ehrs/StructureDefinition/requirements-dependent",
          "valueBoolean" : false
        }
      ],
      "key" : "EHRSFMR2.1-RI.1.3.3-03",
      "label" : "RI.1.3.3#03",
      "conformance" : [
        "SHALL"
      ],
      "conditionality" : false,
      "requirement" : "The system SHALL capture, maintain and render the date, time and user for the original and each updated version of the Record Entry."
    },
    {
      "extension" : [
        {
          "url" : "http://hl7.org/ehrs/StructureDefinition/requirements-dependent",
          "valueBoolean" : false
        }
      ],
      "key" : "EHRSFMR2.1-RI.1.3.3-04",
      "label" : "RI.1.3.3#04",
      "conformance" : [
        "SHALL"
      ],
      "conditionality" : false,
      "requirement" : "The system SHALL manage the succession of Record Entries in chronological version order."
    }
  ]
}

XIG built as of ??metadata-date??. Found ??metadata-resources?? resources in ??metadata-packages?? packages.